DevOps 转型时如何安全融入？对企业产出有何影响？2019年 DevOps 最新现状研究报告解读 | 原力计划

作者 | liumiaocn

 责编 | 徐威龙

封图| CSDN 下载于视觉中国

2019年DORA发布了DevOps的研究报告，迄今为止这已经是DORA的第八次报告的发布。相较于往年的报告，2019年的报告全篇只聚焦于一个要素：安全。

在2018年DORA提供了一个包含五个步骤的模型来帮组企业更好地开展或者推进DevOps的实践，而将安全与DevOps实践进行融合的时候，往往发现会存在很多困难，这份报告将会从多个方面对安全的融入进行展开分析。接下来让我们来看一下这份报告能够给我们带来哪些启迪。

• 研究人员
  

随着理念的推广，DevOps不再只停留在词汇和概念的程度上，已经得到了普遍的接受和认可。与2018年类似，这份报告的主导者仍然是puppet和splunk，除此之外加入了一个新的成员circleci，很有趣的事情是主要作者仍然是下面的四位，连头像都没有变化，唯一的区别是是Michael Stahnke从puppet的director of engineering变成了circleci的VP。不过这些对读者来说并不那么重要，大家所关心的是他们的产出所能带给我们的启发。

• 安全融入所带来的挑战

安全是一个非常重要的概念，需要给予足够的重视，这个想法深入人心，但是在很多项目进行安全实践相关的融合时，都会发现这个想法显得过于理想化，观念上的重视和事实上的轻视在实际的实践中同时被展现了出来。

安全增强相较于功能特性的增强，对于企业来说，并不能时时清晰可感，它更像保险，只有安全事故出现的时候才会觉得后悔，所以特性增强一般会排在首位，其次才是安全增强，而实际上排名“其次”的第二名永远都得不到足够的重视，后面我们也将会使用一些数据来佐证这个观点。

在这份报告中，对企业在实施DevOps转型时如何进行安全融入、以及安全融入对企业的产出的影响，都在报告中给出了结论。

内容概要

1、DevOps的实施会对安全带来正向影响

一般来说，需要在DevOps实践中进行安全融入的企业都是那些已经走过初期阶段企业，DevOps的实践已初见成效，需要在整个企业内部进行展开，这种情况之下，自然需要在安全上进行进一步的强化。

解读：在2019年的调查报告中，DevOps实践很好的团队之中有高达22%的比例达到了安全集成的最高级别。DevOps的CAMS在安全的融入方面同样起效，可靠性、可预测性、可测量行和可观测性不仅仅带来了安全的环境，更为重要地是将这一切结合了自动化之后所带来的安全事件响应速度的效率提升。

好的DevOps文化能够支持更严格的安全策略的贯彻执行，在有着Sharing（分享）的文化的团队之中，团队使用通用的工具，合力完成共同的目标，安全也自然成为了一种共同的责任，在这种文化之下，“部门墙”会相对更为容易跨越，在问题出现的时候，自然也会得到最早地解决。

2、在软件交付中深度集成安全使得团队更加自信

根据调查报告显示，安全级别达到最高级别的受访者有82%对公司的安全有足够信心，而没有进行安全集成的受访者中，这一比例仅达到38%，这一调查结果充分显示在软件交付中，深度集成安全使得团队更加自信。

解读：集成安全并不只是简单的“左移”，而是需要从整体上进行解决，比如强调跨团队的协作、增强自动化在检测和预防方面起到的作用，同时需要打破部门之间的知识孤岛，使得成员都能够参与进来。在安全改进方面使用的最为广泛的几种实践如下所示：

• 团队协作：基于威胁模型分析，安全团队和开发团队增强合作应对安全威胁

• 工具集成：安全工具集成到开发的流水线中，可以增强开发工程师对于其开发的代码中不会引入已知的安全问题的信心。

• 安全需求：从功能性和非功能性综合考虑，将安全相关的需求列到产品任务清单中。

• 人工评审：从安全专家的角度对于自动化测试进行评估，重点包括那些具有较高风险的代码变更内容，比如认证和加密相关部分。

• 基础框架安全：与基础框架相关的安全策略需要在部署之前进行评审。

重点：所有的这些内容大多数公司都知道应该做，但是往往因为种种原因却没有去做，这是一种普遍的情况。

3、在软件交付生命周期集成安全会带来积极结果

调查报告发现：

• 生产环境的按需部署效率提升：安全集成级别较高的受访者所在公司在按需进行生产环境部署方便达到了61%的比率，而安全级别较低的受访者所在公司在这一比例仅能达到49%。

• 修复时间相差不大：调研之前的假定认为安全集成级别较高的公司能够更快部署、更快修复安全性问题，但是实际反馈结果显示在修复问题的时间方面目前相差无几。

• 安全改善效率更高：安全集成级别较高的公司能够在进行功能特性交付的时候更加有效的强化安全改善，在发现交付只生产环境处理安全问题时的处理更有效率。

解读：在软件交付生命周期中安全集成地越深入，交付团队对于团队共同安全责任的理解更加清晰，同时对于对于潜在的对于业务的风险也会降低地更多，安全问题也会得到更多的重视。

4、中间过程可能会是混乱和难熬的

正像DevOps个别的成功推广开来碰到的问题一样，中间的阶段和过程可能是混乱无序、非常难熬的。在项目刚开始的时候，很多未知的问题和障碍还未出现，还没有大面积普及的情况下，往往较为顺利的看到了预定的结果，但是很快随着集成的深入，很多问题就会出现，这就是非常难熬的中间阶段。安全集成也是这样，往往解决了一个问题，就会引入一个新的问题，我们不知道这漫长的中间阶段到底有多长（不过根据经验来看一般比想象的要短，但是难熬的日子往往觉得很漫长）。比如如下是2018-2019年的中间阶段的企业的比例构成：

解读：在难熬的中间阶段，安全的融入所需要的协作、沟通甚至有时会拖慢交付的速度，安全审计的问题会增加，这些都会带来额外的工作和注意力，需要组织级别同时相应地根据情况进行变化以适应，但是这都是中间阶段所需要处理的细节问题。抱着必定得到拯救的信心坚持下去吧，光明就在前方，除此之外我们也别无选择。

而从2018和2019年连续数据也能够佐证这一观点：虽然整体在不断成熟，但是除去做的非常完善的和尚未起步的，连续两年卡在中间的企业都高达79%，说明DevOps演化还将是一个长期的过程。

数据来源

1、区域

整个亚洲占到整体调研数据的19%

解读：按照国家来确认，中国的反馈占到这19%的8%，所以这份调研报告所能体现出中国在其中的比例大概为1.5% （19% * 8 % ），所以这又是一份基本不能代表2019年中国DevOps最新发展状况的数据，但是对于整体的发展趋势可以有所了解。

2、行业与规模

科技与金融仍然撑起半壁江山，而零售/通信/教育/医疗/政务/健康/保险/制造等主要行业也达到40%左右，整体行业均有涵括，非盈利的机构依然能够占到1%的比例。

2019年对组织大小的判断继续延续2018年的方式，定义在年度营业收入，使用annual revenue将组织进行划分，10亿美元以上的组织占到28%，相较于2018年略有提高，相较于2018年低于100M$营收的公司44%的比例下降至30%，其余规模的组织比例也较为均衡。

3、角色

受访者仍然以管理人员偏多，IC（Individual Contributor）仅占26%，这一比例很巧合地跟2018年完全一致，其他成员的比例也大体相差无几。

4、DevOps团队

随着DevOps理念和实践的不断推广，与DevOps团队相关的工作人员也开始逐年递增，以下是到2018年DevOps团队的占比情况：

在2019年，由于团队的人员的职责进一步细化，在2019年显示的DevOps团队仅占22%。

解读：看似下降的比例，但是考虑到如下三部分都属于DevOps的范围，比例已经为22% + 4% + 2% = 28%

• Site reliability engineering：4%

• Release engineering：2%

• DevOps：22%

• 同时在2019年重点融合的安全相关的部分，也同样可以认为是DevOps团队的延伸，所以结合起来仍然在进一步上升，名称可能有所变化，但是方式和职责明显是更为细化和清晰。

• Information security / security operations：6%

• Compliance & audit：1%

DevOps实践中的安全集成

1、DevOps的演进模型中的安全集成

在2018年的报告中提出了企业在DevOps演进时的5个阶段的模型如下所示：

我们可以看到在第4阶段中通过自动化安全策略配置来帮助DevOps在安全方面升至第5阶段，而第5阶段的一个关键实践就是自动化的事件响应，同时安全团队在设计和开发的阶段都进行融入都是第5阶段需要做的事情。

2、安全集成的模式和实践经验

DORA八年的DevOps调研结果显示：当运维需求集成进软件交付流程中，更快的部署、更少的错误、更省时的修复、更少的手工作业都是可以期待的，同样在安全集成的时候在如下方面将会有哪些影响也是我们所关注的：

• 主要的软件交付性能指标

• 安全问题的响应

• 组织发现安全问题的方式

• 对待审计的态度和方式

解读：成功的DevOps实践可以将本来形同水火的开发团队和运维团队变的亲密无间，同样事情在进行安全的集成也是类似的，好的安全集成可以将互相看不惯的开发运维团队和安全团队变得不分彼此，这样安全问题才会真正成为每个人下意识会去关注的。

3、安全集成的困难之处

安全实践在实际的项目中往往扮演着一个“麻烦制造者”的角色，安全往往被视作部署的瓶颈，它往往发生在交付周期的最后阶段，这些检查往往是手工的，所以往往是造成延迟的重要原因，而一旦查出安全问题，往回意味着开发、测试和运维团队需要对应一些额外的未被计划的工作，这往往使得已经延迟的交付进一步加深。在现实的世界中，往往新的特性快速地投放才是重中之重，带着一些未解决的安全问题先行将特性上线的做法也并不罕见，这种情况下，当时的想法一般会是“在下一个版本中一定要堵住这个有风险的安全漏洞”，但是一旦上线，出于各种原因，就忘记了还有一个洞没有补，导致安全相关的技术债务不断积累。在加上漫长难熬的DevOps演进的中间阶段，安全的集成在实践中举步维艰。但是在这个过程之中，我们还是能够发现一些无论是DevOps演进还是安全集成时都会通用的实践经验：

• 逐步改善的中间过程：中间阶段需要处理的问题非常广泛和复杂，在流程上需要组织跨团队协作以解决手工评审等步骤，同时需要通过自动化来增强管控和追踪性。

• 协作和分享：早期可以通过协作与分享（不仅仅包括信息的分享，还包括责任的共担）很好地进行改善的环节。

• 自动化：在演化的过程中，团队可以使用自动化来解决很多痛点，比如自动部署、比如自动事件响应和自服务能力。

4、DevOps vs DevSecOps

这份调研报告中特意提到了一个词：DevSecOps，但是DORA认为，安全应该只是DevOps实践中的一个部分，但是通过DevSecOps能够广泛引起企业对于安全的重视是值得称道的。

5、安全集成的现状

2019年度对于统计的数据进行分析之后，发现处于非常低的阶段Level 1（Level 1 ～ Level 5的说明在后续章节展开）的受访者只有6%，达到最高安全级别Level 5的比例达到22%，而在通过对于DevOps演进进行分析，也能够发现安全集成在整体起到越来越重要的作用。

6、DevOps演进 & 安全集成

2019年度关于安全集成和DevOps演进的结论:

DevOps演进能够更好地推进安全实践的落地，对于希望对于安全进行改善的组织，继续践行DevOps是一个不错的主意。

安全集成级别

1、安全集成的级别界定方法

对于受访者安全级别的界定，2019年度是通过对于问卷的内容进行设计来达到的，首先需要确认安全在软件交付周期的哪些环节被引入：

• 需求

• 设计

• 构建

• 测试

• 部署

根据受访者在上述环节安全被引入的状况来界定安全集成的等级：

• Level 1: 无集成（在任何一个阶段都未进行安全集成）

• Level 2: 较低程度集成（在一个阶段集成了安全）

• Level 3: 一般程度集成（在两个个阶段集成了安全）

• Level 4: 较高程度集成（在三个或者四个阶段集成了安全）

• Level 5: 最高程度集成（在所有阶段集成了安全）

虽然重点研究落在了软件交付之上，但是从运维角度关于生产环境中安全集成方面也在如下的一些环节进行了确认：

• 脆弱性管理与修复
  

• 安全策略自动化

• 审计发现与响应

2、安全集成现状

通过对于受访者的反馈进行分析，各个级别的比例分布大体如下所示

注意：整体比例加起来是101，可能又是一个无伤大雅的小问题，对于整体状况的把握没有影响。

另外，从Level 2 ～ Level 4由于存在多种组合的可能性，经过调研发现如下模式在目前阶段最为常见：

• Level 1: 仅在生产环境安全事件报告时或审计发生时才会驱动安全相关的工作

• Level 2: 在测试阶段集成安全

• Level 3: 在测试和部署阶段集成安全

• Level 4: 在构建、测试和部署阶段集成安全

• Level 5: 在需求、设计、构建、测试和部署阶段集成安全

3、改善方式

大多数组织对于安全的改善使用了一种迂回的策略，比如关于身份识别和权限控制等都是常见的实践，但是很多企业都没有严格地完整地去做这件事，因为在实际实施中非常困难，这些严格的控制可能会拖慢所有事情的进度，在时间成本和效率上将会付出昂贵的代价。

而经过调研也发现了真正有效并能够带来正向结果的改善方式：从软件的规划和设计开始，对每个阶段进行安全相关的控制才能从整体上带来正向的效果。但是如何才能使得安全能够更容易地进行改善，能否以一种更为敏捷的方式进行，通过不断地迭代来完成？答案也非常简单，重点在于构建增强安全意识的文化，交付团队的成员需要能够具有足够的知识和自动化的手段予以定位安全问题、了解安全问题的处理有限度、具有处理安全问题的足够知识，在此基础上对于安全意识的增强才能够真正落到实处。

4、安全集成与信心的增强

在2019年度的调查问卷中设计了内容用来确认安全集成程度与团队成员信心之间的关联度，从下图可以清晰地看出整体来说信心随着级别的提升而提升。

解读：在安全集成程度最高级别的受访者中有82%的程度表达了他们的信心，而在没有任何集成的阶段这一比例只有38%。可以看到即使是只有最简单程度的集成也能在安全信心方面给团队带来明显的效果。持久的信心非常只重要，因为它能真实体现团队成员对于安全现状的认识，虚幻的信心是无法经受实践的检验的，团队持久的信息实际来源于实际上真正安全的现状，这样在价值的交付时才能做到真正地安全、快速和稳定。

另外，需要意识到更为重要的是安全并不仅仅是将一些安全实践比如渗透测试或者静态代码检查等提前开始，需要改变和重点关注的是跨团队的协作和责任的共担。

5、行之有效的实践建议

报告中还列出了一些对于安全集成有效的实践建议，可以在使用时进行参照：

• 团队协作：基于威胁模型分析，安全团队和开发团队增强合作应对安全威胁

• 工具集成：安全工具集成到开发的流水线中，可以增强开发工程师对于其开发的代码中不会引入已知的安全问题的信心。

• 安全需求：从功能性和非功能性综合考虑，将安全相关的需求列到产品任务清单中。

• 人工评审：从安全专家的角度对于自动化测试进行评估，重点包括那些具有较高风险的代码变更内容，比如认证和加密相关部分。

• 基础框架安全：与基础框架相关的安全策略需要在部署之前进行评审

• 主要变更评审：对于主要的代码变更在部署之前进行安全人员评审

• 安全特定的测试：对于安全相关的特定测试，比如测试应用的使用权限和数据访问权限等。

• 自服务：开发者可以配置按需进行包含安全设定的基础框架和环境

• 设计融合：安全需求被视作普通的设计需求进行处理

• 轻微变更评审：对于轻微的代码变更在部署之前进行安全人员评审

• 安全评审：应用代码发布至生产环境后出发安全评审

• 渗透测试：包含并不仅限于脆弱性相关测试或者黑客工具测试等

• 基础框架配置：基础框架可以进行在安全审批的流程基础上进行自动化配置

• 依赖检查：对于应用和环境进行相关的依赖检查以确认整体的安全性状况

• 静态代码分析：使用静态代码分析工具对于应用进行安全性和脆弱性问题的检查

6、经验总结

• 基于威胁模型的团队协作

来自于交付团队、安全团队和业务关系人等各方人员一同对于安全相关的威胁常见威胁模型，并进行分析，以确认应用和支持应用的基础框架所潜在安全风险，以及出现问题时相关的应对措施。威胁模型有助于在项目最早期的阶段进行规划和设计，同时有助于在开发团队、安全团队以及业务团队之间建立信任和同理心。

• 工具集成提升开发团队的信心

工具并不能解决所有的安全问题，也不存在一个解决所有安全问题的工具，但是可以通过集成工具将例行繁琐的任务进行自动化以提高效率和节省时间，比如可以将静态安全工具的检查对于安全相关的脆弱行的分析进行例行的集成，通过这些工具的集成使得开发成员在开发阶段就可以快速定位可能存在的风险，而在这个阶段进行修改的整体成本也是较低的。

• 在敏捷迭代过程融合安全

随着敏捷理念的深入人心，代码的发布也正在使用一个小而快的方式在迭代周期中不断进行。敏捷方式有助于持续学习和改进，但是对于传统方式下的安全需求的实现则较为困难，因为传统方式往往安全策略的检查等都是手工方式，另外开发团队内所缺少的安全相关知识和经验才是最重要的问题，而实际上这也是融合时的难点所在，有了这样的团队成员在定义敏捷的DoD的时候才有可能将安全需求以可验收的方式提前指定，才能真正地在敏捷开发中融合安全需求。由于大型企业往往是有一个统一的中心化的团队来对所有应用开发团队的交付安全进行统一管控，所有很难保证每个项目都有自己的专门安全人员，所以一个较为折中的方式则是鼓励开发团队成员或者运维团队成员能够具备这方面的知识以帮助团队在快速的迭代中能够进行性安全的融合。

• 基础框架相关的安全评审

使用诸如CIS Benchmark这样的参考，对于进行基础框架相关的评审是一个不错的想法，但这是一个开始，每个项目的基础框架都有可能不同，这就需要安全团队和运维团队一同协作，在部署之前对于基础框架的变更或者引入可能会导致的各种问题进行知识和经验的交换，并在此基础上进行深入探讨和评审以保证部署的安全性。

• 对高风险的代码变更进行安全专家的评估和自动化测试

传统方式下，应用只有在UAT或者准生产环境中，可会受到安全团队的手工确认，如果将此部分的内容进行左移，在更早的阶段由开发这能够通过检查或者自动化测试确认这些风险和不合适的配置，修改的成本将会更低。由于脆弱性的存在有非常广泛的可能性：三方组件、服务器、数据库、网络设备、防火墙、云存储等，为了防止被攻击，我们需要跨团队（比如包括开发、运维、网络、存储、中间件、云计算等）进行深入的知识共享以确保我们的检查和自动化测试是与时共进的，而这些自动化的检查和测试也将安全人员从琐碎的工作中解放出来，可以一起完成一些根据有意义的工作，比如：

1. 和交付团队一起协作确保和测试应用以保证安全性

2. 给予错误的配置已反馈以避免类似的错误配置重复出现

3. 对于高风险的代码变更进行安全相关的评审

• 实践经验的频度和影响度矩阵

根据经验使用的频度以及影响度进行划分，上述列出的实践建议的分类如下所示

7、软件交付生命周期安全集成与正向效果

在软件交付生命周期进行安全集成，会在多个方面带来正向的效果，这包括

8、部署频度

在2019年的调查研究中，设计了“部署能力”和“实际部署频度”的问卷，主要用于确认技术和流程是否对于业务需求的部署有所限制。详细的能力结果如下图所示

解读：从反馈的结果来看也能看到即使是没有做任何安全集成的组织，也可以做到按需部署或者至少一天两次的这种能力，相较于8年之前的调研结果已经发生了翻天覆地的变化，当时部署甚至仍然是按照月的单位来进行衡量的。部署频度稳定地得到了提升，在2017年高能效的组织就可以实现一天多次的部署了，之前是等待部署能力是限制要素，而现在更多的情况已经发生变化，部署能力已经就绪，但是限制要素变成了实际的需求等依赖了。

需要注意的是Level 3，相较于Level 2，按需部署的能力有了明显的下降，这也体现了我们所提到的“痛苦的中间阶段”的描述，这可能是和安全集成交互在走向成熟的过程中的反复，而在Level 4和Level 5就开始重新正向的提升了，而Level 5的按需部署能力更是达到了61%，而实际的按需部署也达到了34%之高。

9、重要安全问题的修复时长

调研之前的假定认为安全级别越高，修复重要安全问题的时长应该会非常明显的降低，而2019年的调查结果却显示并非如此，首先很少有受访者能够在1小时之内修复安全问题，大多数会在一周之内修复安全问题，具体来说：

• 只有7%的受访者能够在1小时之内修复安全问题

• 32%的受访者在1小时～1天之内修复安全问题

• 33%的受访者在1天～一周之内修复安全问题

详细按照各个安全级别对于重要安全问题修复的时长的比例统计，详细信息如下图所示

解读:从这附图中我们可以看到：

- Level 5的受访者中11%可以在1个小时之内修复重要安全问题，相较于Level 2～Level 4的6%，由于目前整体水平不高，还是有较大差距的。

- 观察修复时长在1小时～1天范围之内的统计信息可以发现，Level 1的受访者中有31%能达到此水平，而Level 4和Level 5分别能达到38%和39%，还是有些许的提升的，而中间的下降仍然考虑到是“中间阶段”所带来的反复，同时也是由于更多沟通协作的引入，在成熟之前显然后拖慢相应的速度，显然自动化或者相应的流程改善还有很多余地。

10、安全改善 vs 特性交付

安全改善肯定是需要做的，但是是不是立即要做，在现实的世界中往往需要和特性交付进行平衡，而需要交付的特性往往是那些已经承诺给客户了的，在这种情况下，安全集成程度高的公司在这方面能更好地保证安全改善的切实执行，这很有可能是因为安全的重要性和其价值已经在这些组织中得到了广泛的共识，而在整个DevOps演进的过程中也是这样，只有DevOps演进程度更高的公司在实践这些原则的时候才能做的更好。

但是这个数据显然还有很多改善的余地，比如在安全等级最高的在抉择的时候仍然是49%的选择安全改善，51%的仍然会选择特性交付，潜台词就是，我知道系统这种方式直接交付会有风险，但是不按时交付特性，我会有风险。

特性的交付非常重要，忽视安全改善，忽视数据安全，往往会带来巨大的损失，比如美国征信巨头Equifax，泄露了高达1.47亿用户的信息，被泄漏的信息包括姓名、社会安全号码（SSN）、出生日期、地址、驾驶证号码等，赔偿达到7亿美元。市场竞争激烈，当然尽早进行特性的交付能够更好地占得一席之地，但是安全同样不容忽视，如何进行平衡是需要考虑的重点内容，否则一旦出现安全问题，也会出现巨大损失，同时对口碑也将会有不小的影响。

11、为安全改善停止部署

经过调研发现，安全集成程度较高的公司可以为了对应额各种类型的安全问题更好地停止部署，详细信息可以参看下图：

因为发现了安全的问题停止部署，看起来是非常容易的事情，但是如果这个流程执行高效的话，还需要至少考虑到恢复也能够很快地重新正轨。当然最为重要的还是降低了风险，使得系统免受了可能的风险。

解读：停止部署这件事情背后的意义在于，在一个大型的项目之中，因安全问题停止部署这样的决定往往是一个中心化的安全团队来做的，而现在将能力赋给了交付团队，充分体现了分享的另外一层含义：责任共担，这也是安全集成级别高的团队所体现的一个重要特点，所有的团队成员对于安全的意义和责任能充分意识，这种做法也避免了传统方式下可能出现的官僚做法。

12、安全责任共担

在传统的大型组织中，安全往往被视作安全团队的责任，主要原因是，安全是一个比较专业的领域，包含的专业知识角度；另外，思考的方式往往与普通编码作业有所不同：更多的考虑代码失败的方式而不是正常动作的方式；开发者更为关心如何更快构建和发布新的特性，而在安全团队成员来看，这可能并不是最重要的。一个整体的安全集成方式可能包含：在需求阶段识别的安全需求、编码阶段遵循的安全代码规约、测试阶段的脆弱性持续测试、生产环境的日志和监控。

• 修复的阶段与成本
  

而所有的这些：整体的安全集成以及安全责任共担都是为了能在更早的阶段发现安全问题，根据IBM的一项研究，显示缺陷的修复越早成本越低，在实现阶段的成本是设计阶段的6倍，而在测试阶段则上升至15倍，而部署至生产环境之后此成本则上升至100倍。而对于安全缺陷，所付出的成本可能会更高，比如一旦攻击者利用生产环境中的漏洞获得现金账户，将直接导致实际的资金的丢失的巨大风险，另外数据也可能会被卖给竞争对手，客户数据的丢失还直接会使地公司被诉讼至法院，同时可能会丢失客户的信任和市场的份额，这些都不是危言耸听。

• 外部依赖与安全问题

另外，很容易陷入的一个思维误区就是仅仅考虑代码自身所导致的安全问题，而实际上在现代的系统中，几乎不可避免的受到各种开源工具或者相关的开发框架以及依赖的影响，这些关联的外部依赖是否有安全问题也是系统整体安全所必须考虑的问题。根据Snyk在2019年关于开源安全的调研报告，当今软件中整体来说有接近78%的脆弱性问题就是由于这种间接的依赖所导致的，所以修复这些关联部分所产生的安全问题显得尤为重要。

• 安全共担的意识

调查显示，安全集成程度越高，对于安全应该是共同承担的责任这一意识的认同度越高，从下图的调查统计数据中可以看到Level 1和Level 5之间的差距达到31个百分点之多。

无论是安全团队人员还是普通成员，对于安全责任共担这一观点基本相同，详细比例可参看下图

13、安全集成 & 审计结果

在2019年的调查中就安全审计和所确认出来的三类安全性问题的频度进行了确认：需要立即更正的问题、需要作为较高优先度更新的问题以及较低优先度需要更新的问题，详细内容如下图所示：

可以清晰地看到，审计所能发现的这三种类型的安全问题，随着安全级别的生狗都是有一个明显的爬升和回落的状态。

解读：Level 1基本没有安全相关的集成，自然发现的问题较少，而Level 5则是较为成熟，很多问题在早期阶段就已经处理，同时大部分既存的问题也都得到了解决，是安全问题本身就很少的成熟阶段，而中间阶段是逐渐开始深化安全集成的部分，自然会发现很多的问题需要对应，这和前面的结论也能够保持一致。

14、J曲线效应

安全集成的确能够带来正向的效应，但是通往成功的道路并非一帆风顺，本文已经多次介绍过一些安全集成时的一些J曲线效应（本应该上升的趋势却在早期显示为完全相反的趋势，只有越过这个阶段才能显示出原本应该显示的趋势）

• 2016年的研究报告发现：中等绩效者会比低绩效者还要花更多的时间在rework上。

• 2017年的研究报告发现：中等绩效者会需要比低绩效者做更多的手工作业

解读：这都显示了J曲线的效应，一旦开始改善，打破原有的流程、规范和方式，反而可能会带来一定的负面效果，套用一句常用的话来进行总结：前途是光明的，道路是曲折的，内心是坚定的。至于卡在中间的探索者能够看到最后的光明还是死在黎明前的至暗时刻，这不仅仅是勇气和毅力的考验，还有团队的支持和理解都非常重要。

• 团队间的摩擦

而关于安全集成是否能够以一种非常和谐的方式进行，如下图所示的J曲线再次施展了它的魔力。

而J曲线也不因是否是安全团队的成员而改变它的形态

解读：这也使我们清醒地认识到，安全的集成所需要的跨团队的融合，在达到成熟之前是无法避免摩擦的存在的，所以正视摩擦的存在，坚定信心最终是能够跨越这个困难的终结阶段的。

• 拖慢了的交付速度

而关于安全集成和软件交付速度之间，同样存在类似的问题，安全集成成熟度正处在中间的Level 3的受访者有48%认同安全集成是拖慢软件交付的重要原因之一。

解读：每次当我们觉得已经做好足够心理准备来面对可能会出现的J曲线的反复，数据会告诉我们，我们还没有做好准备？所以当有48%的处在Level 3的身处其中人会认为安全集成和改善确实拖慢了交付速度的时候，当我们按照这个节奏成为这48%之中的一员时，我们还能否说出：前途是光明的，道路是曲折的，内心是坚定的？

• 发现了更多问题

J曲线再次不负众望，再次告诉我们，安全集成并不意味着所发现的问题更少，这里我们再次看到熟悉的曲折过程

解读：实际上这个问题多少已经有所不同，直至Level 5仍然比Level 1的程度要高，但是这并不是一个问题，安全问题就在那儿，我们对应还是不对应，都改不了它存在的本质，把头埋在沙子里或者掩耳盗铃并不是聪明者的做法，而且明显地可以看到整体的趋势会向好，这才是这个统计结果所反馈给我们的内容。

15、理想的组织结构

不只是进行安全集成，在整体进行DevOps实践的过程中，被问到的最多的问题之一大概就是“推动DevOps实践时理想的组织结构是什么样的？”，目前的答案可能会另很多人失望：“需要视情况而定”。确实为了更好地实施DevOps，组织结构需要调整成什么样子才更有效率会有很多制约因素，比如包括：

• 组织文化

• 组织结构的灵活程度

• 团队成员和团队领导者之间的关系

• 职能团队分割的状况

• 团队成员知识技能的实际状况

• …

虽然很难给出答案，但是就如同2018年的调查内容一样，调查结果本身对我们可能就有一定的参照性，2019年根据调查者的反馈，根据组织大小不同，安全职能相关的组织结构如下图所示：

而安全集成程度和组织结构的关系如下图所示：

从中我们可以看到：

• 有48%的受访者拥有一个中心化的安全团队对于交付团队提供按需支持的能力，超过10亿美金营收的企业这一比例达到57%。

• 有31%的受访者拥有一个中心化的安全职能，而交付团队本身也有安全相关的专家成员，营收在1亿～10亿美金之间的企业这一比例达到46%

• 只有14%的受访者有着去中心化的安全职能结构，每个交付团队都有着自己专职的安全专家，这种结构对于营收在1百万一下的小型公司中更为常见。

解读：需要注意的是Level 3中无论是按需的中心化职能从Level 1的57%下降至44%，而同时是否有专职的安全专家方面的比例也有了一个非常显著的提升，根据调研报告的分析推测，大概是在Level 1～Level 2的时候这方面并没有足够的资投资，而到了Level 3，随着安全集成的成熟度的升高，对此也越加重视，所以团队有了专门的安全专家予以支持，听起来也比较合理，在2020年后续的调查中是否展开我们也将会继续确认。

总结

在DevOps的演化中，安全的集成和演化发生在较后的阶段这并非偶然，跨职能团队的协作和责任共担的理念需要团队不断成熟才能更好地理解和执行，安全的融入也是这样，就像早期我们打破开发和运维之间的那堵墙一样，安全的融入需要同样的方式和原则来打破部门的隔阂，虽然不可避免地会出现J曲线的看似反复的曲折过程，但是达到成熟阶段的整体方向和趋势是不会改变的。

参考内容

https://puppet.com/resources/report/state-of-devops-report/

https://wiki.owasp.org/index.php/Category:Threat_Modeling

https://owasp.org/www-project-top-ten/

声明：本文为CSDN博主「liumiaocn」的原创文章，博文链接：https://blog.csdn.net/liumiaocn/article/details/104890968。

推荐阅读：

真香，朕在看了！